継続的デリバリー

継続的なデリバリーとは、チームがソース コード リポジトリから本番環境まで、自動化された方法で高品質な製品を頻繁かつ予測可能な方法でリリースするアプローチです。

一部の組織では、以下の図に示すように、あるチームから次のチームへと製品を手渡しながら手動でリリースしています。通常、開発者がこの図の左端にいて、運用担当者が受け取り側にいます。そのため、引き継ぎのたびに遅延が発生し、チームと顧客の不満につながります。製品は最終的に、面倒でエラーが発生しやすいプロセスを通じて稼働し、収益創出が遅れることになります。

それでは、以下の継続的なデリバリー パイプラインをご覧ください。この図は、開発者が各自のラップトップでコードを記述して、その変更を Bitbucket などのソース コード リポジトリにコミットする方法を示しています。コードとは、テスト対象のシステム、テスト、およびシステムのデプロイと保守に使用されるインフラストラクチャを意味します。Bitbucket Pipelines は、製品をテスト環境からステージング環境、本番環境へとリリースして、顧客が最新の機能を利用できるようにします。

継続的なデリバリー パイプラインでは、本番環境の直前に手動ゲートを設けることがあります。手動ゲートには人の介入が必要で、組織によってはパイプラインに手動ゲートが必要なシナリオがあります。手動ゲートには問題のあるものもあれば、正当なものもあります。正当なシナリオの 1 つとして、ビジネス チームが土壇場でリリースを決定できるようにすることが挙げられます。エンジニアリング チームは各スプリント後に製品の出荷可能なバージョンを準備し、ビジネスチームは製品をすべての顧客、特定の層、または特定の地理的場所に住む人々のいずれに対してリリースするかの最終決定を下します。

パイプラインを通過する製品のアーキテクチャは、継続的なデリバリー パイプラインの構造を決定する重要な要素です。高度に結合された製品アーキテクチャでは、複雑なグラフィカル パイプライン パターンが生成され、最終的に本番環境に到達する前にさまざまなパイプラインが絡み合う可能性があります。

製品アーキテクチャは、パイプラインのさまざまなフェーズと、各フェーズで生成されるアーティファクトにも影響を与えます。パイプラインは最初にコンポーネント (製品の最小の配布可能でテスト可能な単位) を構築します。たとえば、パイプラインによって構築されるライブラリは、コンポーネントと呼ぶことができます。これがコンポーネント フェーズです。

疎結合されたコンポーネントはサブシステム (デプロイおよび実行可能な最小単位) を構成します。たとえば、サーバーはサブシステムです。コンテナー内で実行されるマイクロサービスもサブシステムです。これがサブシステム フェーズです。コンポーネントとは対照的に、サブシステムは立ち上げてテストできます。

そのため、システム全体を一括でリリースする必要がある場合、パイプラインは疎結合のサブシステムからシステムを組み立てるように設定できます。これがシステム フェーズです。

このオール オア ナッシング アプローチでは、最も高速なサブシステムが最も低速なサブシステムの速度に合わせることになります。「鎖の強さは最も弱い環の強さで決まる」というのは、このアーキテクチャ パターンに陥るチームに警告する際によく使われる決まり文句です。

検証が完了すると、組み立てられたシステムは、それ以上の変更を加えることなく、最終フェーズである本番フェーズに移行されます。

これらのフェーズは物理的というよりも論理的なものであり、大きな問題を複数の小さなサブ問題に分解するためだけに作成されることに注意してください。アーキテクチャと要件に応じて、フェーズの数は少なくなる場合も増える場合もあります。

品質を伴わないスピードは、お客様にとって無意味です。継続的なテストは、自動テストをソフトウェア デリバリー パイプラインに統合し、パイプラインを通過するすべての変更を検証する手法です。テストはパイプラインの各フェーズで実行され、そのフェーズで生成されるアーティファクトを検証します。ユニット テストと静的コード解析は、パイプラインのコンポーネント フェーズでコンポーネントを検証します。機能テスト、パフォーマンス テスト、セキュリティ テストは、サブシステム フェーズでサブシステムを検証します。統合テスト、パフォーマンス テスト、セキュリティ テストは、システム フェーズでシステムを検証します。最後に、スモーク テストは本番フェーズで製品を検証します。

ソフトウェア デリバリー パイプラインはそれ自体が製作物であり、ビジネスにとっての優先事項です。そうでなければ、収益を生み出す製品をパイプラインを通じて送るべきではありません。継続的なデリバリーは 3 つの方法で価値を付加します。それは、ソフトウェア開発チームのベロシティ、生産性、持続可能性の向上です。

継続的なデリバリーを採用する最適なタイミングはいつでしょうか? それはもうとっくに過ぎています。
チームは次のような優先順位付けされた単一のバックログを必要としています。

継続的なデリバリーは正しいやり方ですが、変革を加速させるためには、時にチャンピオンの存在が不可欠です。適切に設計されていれば、継続的なデリバリー パイプラインは最終的に採算が取れます。

それでは、誰に任せればよいでしょうか?

一部の組織では、経験の浅い人物に継続的なデリバリー パイプラインの設計と実装を任せてしまい、その複雑さを身をもって学びました。経験の浅いメンバーを任命すると、継続的なデリバリーは優先度が低いかのような印象を与える誤ったシグナルをチームに送りかねません。テクノロジーとビジネスに造詣が深いシニア アーキテクトを任命することを強くお勧めします。

継続的なインテグレーション、テスト、デリバリー、デプロイ、分析のどの段階にいるかに関わらず、その中心にあるのはチェックリストでも宛先でもなく、継続的な改善です。

遅かれ早かれ、継続的なデリバリーのパイプラインが構築されるときは、組織の全員が参加することになります。エグゼクティブ、エンジニアリング、製品管理、ガバナンス、リスク、コンプライアンス、情報セキュリティ、オペレーション、法務、その他あらゆる部門で、パイプラインがサイロや壁を打ち崩すでしょう。全員が何らかのかたちでこの変革の一端を担い、継続的組織が新しい標準となるのです。